第七章：提交與指責

應用理論：權力動力學 (Power Dynamics)

「綠洲計畫」的全員大會像一顆投入平靜湖面的石子，激起的漣漪久久未散。那面貼滿了便利貼的「問題之牆」被完整地保留了下來，成為辦公區一個醒目又尷尬的存在。它像一面鏡子，時刻提醒著每個人團隊的困境。

根據現場的投票和艾佛勒的引導，團隊最終決定將第一個為期兩週的行動研究Sprint，聚焦在一個被最多人提及的痛點上：「前後端溝通與協作」。

為了深入理解這個痛點背後的動力，艾佛勒將他的觀察視角，從泛泛的系統行為，聚焦到了更細微的權力動力學 (Power Dynamics) 上。他發現，「溝通不暢」只是一個表象，其深層根源在於團隊內部不成文的權力結構和資源分配。

這個權力結構的頂端，無疑是資深後端工程師，大衛。

大衛是「方舟平台」的初創員工之一，平台的底層架構幾乎由他一手打造。他對系統的每一個角落都瞭如指掌，但也因此，他成了整個團隊的知識核心和技術瓶頸。所有重大的技術決策都需要他點頭，所有棘手的Bug最終也都要匯總到他這裡來解決。這種「被需要」的感覺，在過去的幾年裡，無形中鞏固了他的權威。

艾佛勒觀察到，這種權力體現在日常工作的方方面面：

• 資訊權 (Information Power)： 大衛掌握著關於系統核心運作模式的絕大多數資訊。當別人向他請教時，他傾向於只給出「解決方案」（「你這樣調用就行了」），而不是解釋「為什麼」（「因為這個模組的狀態管理是這樣設計的……」）。這使得其他人只能被動地接受指令，而無法真正學習和成長，從而進一步鞏固了大衛的資訊壟斷地位。

• 專家權 (Expert Power)： 在技術方案的討論會上，一旦大衛發表了意見，其他人很難再提出反對聲音。即使有人鼓起勇氣提出不同看法，大衛也常常會用一些高深的技術術語或反問（「你考慮過這樣做的併發風險嗎？」）來讓對方知難而退。久而久之，會議就變成了大衛的「一言堂」。

• 連結權 (Connection Power)： 作為公司的元老，大衛與CTO穆拉提及其他高層有著更直接的溝通渠道。團隊成員普遍認為，大衛的意見更容易被上層採納。這使得大家在與他發生分歧時，會下意識地選擇退讓。

這種權力結構，直接導致了前端團隊的「失權」。

前端團隊由更年輕的工程師組成，他們充滿活力，渴望引入新的技術和框架來改善用戶體驗。然而，他們的工作完全依賴於後端團隊提供的API。艾佛勒發現，一個新的API從提出需求到最終上線，流程是這樣的：

1. 前端工程師馬克在Jira上開票，詳細描述需要的資料格式和功能。

2. Ticket被指派給大衛，但通常會在他的待辦列表裡停留好幾天。

3. 大衛在評論區提出質疑，認為這個需求不合理，或者會增加伺服器負擔。

4. 馬克和PM需要花費大量精力去解釋和溝通，說服大衛這個需求的必要性。

5. 在漫長的拉鋸後，大衛終於同意開發，但他提供的API格式往往與前端期望的不完全一致，缺少一些關鍵字段，或者資料結構非常不友好。

6. 當前端在開發中遇到問題時，大衛的回應通常是：「API是按照規格給的，是你自己不會用。」

這個流程被前端團隊戲稱為「乞討式開發」。在這個權力遊戲中，後端是資源的「供給方」，而前端則是「需求方」，地位完全不對等。Jira Ticket和Code Commit成了他們劃分責任、互相指責的工具。每一次Commit（提交代碼），都可能伴隨著一次Blame（指責）。

另一個權力的關鍵節點是DevOps團隊。他們掌握著發布權 (Deployment Power)。由於線上頻繁出錯，DevOps團隊建立了一套極其繁瑣和嚴格的發布審批流程，任何上線申請都需要提前三天報備，並填寫大量的檢查清單。這本是出於好意，卻在客觀上給了他們否決或延遲發布的巨大權力。開發團隊常常抱怨他們「官僚」、「死板」，而DevOpes團隊則認為自己是在為大家「收拾爛攤子」。

在一次與艾佛勒的訪談中，穆拉提憂心忡忡地說：「大衛是公司的寶貴資產，我不能打擊他的積極性。但他的風格確實……」

艾佛勒一針見血地指出：「穆拉提技術長，權力本身是中性的，問題不在於大衛擁有權力，而在於權力沒有被制衡，也沒有被賦予相應的責任。系統給予了他『守門人』的權力，卻沒有建立讓他『賦能他人』的機制和責任。我們第一個行動研究的目標，不是去削弱大衛的權力，而是要重新設計協作的規則和場域，讓權力從『個人擁有』轉向『流程擁有』，讓團隊的成功不再依賴於某個英雄，而是依賴於一個健康的協作系統。」

聽完這番話，穆拉提明白了。他們要挑戰的不是某個人，而是一個根深蒂固的、圍繞權力分配而形成的互動模式。而這，比單純的技術問題要棘手得多。

「綠洲計畫」的第一場硬仗，即將圍繞著一張小小的API設計稿，正式打響。